Detect recovery after no_progress attempts

The recovery classifier only treats a previous call as recoverable when previous.result === 'error', but many failed MCP tool attempts are recorded as resultStatus: 'no_progress' while the activity tracker result stays 'success' (see the success-path call to recordRecoveryTrajectory(..., result.isError ? 'no_progress' : 'success', ...)). In that common path, a follow-up successful tool will never be labeled recovered, so the new ledger undercounts recoveries and misclassifies trajectories. This is observable whenever a tool returns isError: true instead of throwing, then a different tool resolves the issue.

Useful? React with 👍 / 👎.

Avoid blocking tool calls with synchronous ledger I/O

record() performs mkdirSync, appendFileSync, and later sync reads/writes (enforceBounds/readRecent), and this method is invoked for every tool completion from handleToolsCall (success and error paths). Node’s fs docs explicitly note that synchronous APIs block the event loop, so this telemetry path can add request latency and stall concurrent sessions under load instead of staying passive as intended (https://nodejs.org/api/fs.html#synchronous-api).

Useful? React with 👍 / 👎.

Bound session index growth in recovery ledger

lastNodeBySession is written on every record but never pruned, so a long-lived server that sees many distinct sessionId values will keep growing this map indefinitely even though on-disk nodes are bounded. This introduces a process-level memory leak over time for high-churn or multi-tenant workloads.

Useful? React with 👍 / 👎.

Restrict recovery detection to the same tab context

Recovery classification is currently session-wide, so interleaved multi-tab activity can be mislabeled as a recovery: a failed call on tab A followed by a successful different tool on tab B will satisfy previousFailed/previous.toolName !== toolName and be recorded as recovered even though no recovery occurred for tab B. Because tabId is already available in args and persisted in nodes, the previous-call lookup should be scoped to matching tab context before marking recovery.

Useful? React with 👍 / 👎.

Mark no_progress outcomes as stuck in progressStatus

progressStatus is derived from current?.result === 'error', but non-throwing tool failures (MCPResult.isError) are mapped to resultStatus: 'no_progress' while the activity tracker still records them as success, so these failed attempts are always stored as unknown instead of stuck. This loses the primary signal this ledger is meant to capture for stale-ref/no-progress flows.

Useful? React with 👍 / 👎.

Redact camelCase secret keys in argument summaries

The sensitive-key pattern only matches when terms like token, session, or auth are standalone or separated by _/-, so common camelCase fields such as accessToken, sessionId, and authHeader are not treated as sensitive. In summarizeArgs, those values are then stored verbatim (unless longer than 200 chars), which can write live credentials into trajectory.jsonl and violates the ledger’s redaction guarantees.

Useful? React with 👍 / 👎.

Redact camelCase token/session fields in arg sanitizer

The sensitive-key regex only matches whole words delimited by start/end, _, or -, so common keys like accessToken, idToken, refreshToken, and sessionId are not treated as secrets and will be written in cleartext when their values are short. Since summarizeArgs is used for ledger persistence, this leaks auth material into .openchrome/recovery/trajectory.jsonl in normal tool-call payloads, which violates the ledger’s redaction guarantees.

Useful? React with 👍 / 👎.

Derive parent node from the same tab context

buildNode falls back to lastNodeBySession, so in a session with multiple tabs the parentNodeId chain will hop across unrelated tabs whenever calls interleave. This corrupts trajectory topology (e.g., tab B nodes can become children of tab A failures) and makes downstream recovery analysis inaccurate even though tabId is tracked separately. Parent lookup should use the same session+tab context key used by getLastNode when no explicit parent is provided.

Useful? React with 👍 / 👎.

Bound per-tab context index growth

lastNodeByContext is appended on every new sessionId+tabId pair, but pruning is only triggered by lastNodeBySession.size; a long-lived single session that churns through many tab IDs will never hit this condition. In that case the context map grows without bound, increasing memory usage and keeping stale context entries indefinitely. Add an explicit cap/prune path for lastNodeByContext (or per-session tab contexts) independent of session count.

Useful? React with 👍 / 👎.

Redact tool result before recording recovery trajectory

recordRecoveryTrajectory is called with the raw result before the existing redactSecrets(result) pass runs, so any tool response that echoes a substituted secret can be persisted to .openchrome/recovery/trajectory.jsonl via observationSummary. This only occurs when a tool result includes literal secret text (for example after ${SECRET:...} substitution), but in that case it creates a disk-level secret leak even though normal MCP responses are redacted.

Useful? React with 👍 / 👎.

Redact secret-like substrings in plain string arguments

The argument sanitizer currently keeps any short string value verbatim unless its key matches LARGE_VALUE_KEY_RE, so inputs like url, query, or value can persist credentials in cleartext (for example OAuth codes or token= query params) into trajectory.jsonl. This violates the ledger’s redaction guarantees because sensitive data often appears in values even when the field name is non-sensitive; apply content-level redaction/hashing to all string values, not only key-based cases.

Useful? React with 👍 / 👎.

Exclude aborted attempts from recovery detection

Recovery detection treats aborted as a prior failure, so a tool call aborted due client disconnect can cause the next successful different tool in the same context to be labeled recovered. That inflates recovery telemetry with non-recovery events (cancellation/network interruptions), making downstream analysis inaccurate; previousFailed should only include actual failure modes such as error/no_progress.

Useful? React with 👍 / 👎.

Redact secret-like values in non-sensitive arg fields

The new ledger can still persist raw credentials when they are passed under ordinary keys (for example, note, url, or query) because short strings are only redacted by key name heuristics and length. In sanitizeObject, any string on a non-matching key and ≤200 chars is written verbatim, so a token embedded in a normal field will be stored in argsSummary, which contradicts the “no raw secrets” safety goal for this telemetry sink.

Useful? React with 👍 / 👎.

Skip malformed JSONL entries instead of dropping all history

readRecent parses the entire file with a single map(JSON.parse), so one malformed/truncated line (e.g., after interruption during append) throws and causes the catch path to return only in-memory pending nodes. That effectively hides all persisted recovery history until manual cleanup, which can invalidate recovery telemetry analysis from otherwise valid earlier lines.

Useful? React with 👍 / 👎.

Chunk stdout by bytes rather than UTF-16 code units

Slicing output with String.prototype.slice can split a UTF-16 surrogate pair when a non-BMP character falls on a 16,384 boundary, so the two halves are encoded separately and emitted as replacement characters; that corrupts the JSON stream and can make --introspect-tools-list output unparsable for clients when tool metadata includes astral Unicode (e.g., emoji). Chunking should be done on a Buffer (byte boundaries) or via a stream writer that preserves code points.

Useful? React with 👍 / 👎.